As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to these users is an information handling system. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may vary with respect to the type of information handled; the methods for handling the information; the methods for processing, storing or communicating the information; the amount of information processed, stored, or communicated; and the speed and efficiency with which the information is processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include or comprise a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Microprocessor speeds have increased dramatically, outstripping memory-access speeds. Although, in the past, microprocessors were slower than their attached storage units, microprocessors must now wait for storage units to complete memory-access requests before completing their tasks. Adding multiple microprocessors to information handling systems, as may be done in servers, only compounds the problem. To reduce delays resulting from memory-access wait times, multi-processor information handling systems may incorporate a Non-Uniform-Memory-Access (“NUMA”) architecture in which the memory access time for the different microprocessors depends on the memory location. Each microprocessor is close to some memory locations, such as local memory, and farther from other memory locations, such as memory local to a different microprocessor or shared between microprocessors. Under the NUMA architecture, a microprocessor in the information handling system can access its local memory quicker than it can access non-local memory.
Although using a NUMA architecture can reduce memory-access delays, certain NUMA-based systems still suffer delays because their operating systems inefficiently allocate memory resources among the different microprocessors to complete requested tasks. For example, some microprocessors in the information handling system may not have any local memory, and other microprocessors may have only limited amounts of local memory available. The operating system may not know the distribution of memory units among the microprocessors in the information handling system, and simply allocate memory arbitrarily—even memory that is distant and inconvenient—to a given microprocessor to allow the microprocessor to complete requested tasks. This system of memory allocation is highly inefficient and can increase memory-access times.
The Advanced Configuration and Power Interface (“ACPI”) specification allows for tables that describe the architecture of the information handling system so that the operating system may allocate resources more efficiently. These tables include entries that describe the affinity between a microprocessor and the various memory units in the system. An operating-system-friendly interface called the “Static Resource Affinity Table” (“SRAT”) can store processor-memory affinities for a particular information handling system. The SRAT, as defined in the ACPI specification, however, does not have the capability to define multi-level memory and multi-processor dependencies for multi-processor systems, such as NUMA-based systems. While this problem can be solved by adding the System Locality Information Table (“SLIT”) defined in the ACPI 3.0 specification, current server operating systems, such as Windows 2003 and Windows 2003 R2, often do not support SLITs. Moreover, the population of a SLIT depends only on the distance between the memory unit and the microprocessor. Thus the SLIT values fail to take into account other variables that can affect memory access times, such as link speed, hop count, and the amount of memory associated with a particular link and microprocessor.